Replace the typedoc HTML site with a VitePress-based documentation site. The hand-written guides lead the navigation, and the generated API reference becomes a single collapsed sidebar section instead of the whole site. The v1 docs at the domain root get the same shell with their content unchanged.

Motivation and Context

The deployed docs are a typedoc dump: a page per symbol dominates the site and the actual guides are buried under a "Documents" entry. This makes the guides the site, keeps the full API reference one click away (rendered as markdown, one page per package), and gives the v1 and v2 docs a consistent look and navigation.

No guide content is rewritten in this PR — existing pages are carried over as-is, with two mechanical transforms: {@linkcode …} tags become plain code spans (VitePress does not resolve typedoc link syntax), and relative links that point outside docs/ become GitHub URLs.

How Has This Been Tested?

• pnpm docs:build — typedoc (warnings as errors) + VitePress build with dead-link checking: 0 warnings, 0 dead links.
• bash scripts/build-docs-site.sh — the full two-site deploy artifact (v2 at /v2/, v1 at /, with the v1 leg built from origin/v1.x) builds end to end from a clean tree.
• git diff over docs/ audited to confirm only the mechanical transforms; pnpm sync:snippets --check, pnpm -r typecheck both green.
• Both sites previewed locally (navigation, search, API reference sidebar, light/dark, the version banners).

Breaking Changes

None at runtime; this only touches docs tooling and CI for docs.

• pnpm docs:check now builds the site (typedoc warnings + dead links) instead of running typedoc alone.
• scripts/generate-multidoc.sh is replaced by scripts/build-docs-site.sh.
• After this merges, the v1.x branch's copy of deploy-docs.yml should be updated (or its push trigger removed) — as it stands, a push to v1.x would redeploy the old typedoc layout over the site.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

• The site's landing page is generated from the repository README.md at build time (docs:index), so the README stays the single source of truth — the same model the v1 site uses, and the same landing the previous typedoc site had.
• The API reference is generated at build time (typedoc-plugin-markdown + typedoc-vitepress-theme, outputFileStrategy: modules — one page per package, not per symbol) into docs/api/, which is gitignored; nothing generated is committed.
• sync:snippets --check is now part of check:all, so snippet drift fails the PR gate rather than only the local pre-push hook.
• The deploy workflow gains an explicit pnpm install step (the old script installed inside a throwaway worktree; the new one builds the current checkout).
• The v1 pages have no top-level heading in the v1.x markdown (the old typedoc shell supplied page titles), so the v1 build step prepends one per page; the v1.x branch itself is untouched.